システム開発にビジネスという観点が加わった入社9ヶ月を振り返ってみた

クラメソビギナーズの「圧倒的成長」アドベントカレンダー2020

#ポエム

hagiwara

2020.12.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本エントリはクラメソビギナーズの圧倒的成長 Advent Calendar 2020の13日目の記事です。

こんにちは。CX事業本部の hagiwara です。

2020年4月にクラスメソッドにジョインしました。
CX事業本部では、採用決定後に配属チームを希望できる制度があります。自分は保守と開発の両方を行っている部内では比較的大きなチームを希望しました。

これまでは、新規開発を行い、リリースして終了ということが多かったのですが、リリースって終わりじゃなくて始まりなのでは？、サービスは継続しているっぽいけど実際自分の書いたコードはどうなったのだろう？と、ずっとモヤモヤしていました。それが解消できるのではと考え、今のチームを希望しました。

結果どうだったか、振り返っていこうと思います。

やったこと

有効会員350万人という大規模なサービスに携わっています。
システムとしては大規模なのですが、多くのマイクロサービスが連携している形で、個々のコンポーネントはそこまで大規模にならないようにデザインされています。
具体的な開発内容は以下です。

既存API群の機能追加、パフォーマンス改善 (Play in Scala on EC2)

お客様やモバイルアプリチームと共にバックエンドチームの一員として、スクラム開発を行っています。
プロダクトオーナーのお客様と頻繁にコミュニケーションをとることができ、ビジネス的な観点を共有いただけるので、開発者側もビジネスを意識して取り組むことができます。
また、ユーザーが多いので、SNSなどでリアクションをタイムリーに知ることができたりします。

新規APIサービス構築 (Spring WebFlux in Kotlin on ECS Fargate)

技術選定からメインで担当させていただきました。高負荷になる可能性が高いAPIで、パフォーマンスが求められたこともあり、WebFlux を採用しました。
Thread per Request ではなく、Event Loop なので Thread Pool に神経を使わなくていいのが楽という印象でした。DB Connection Pool の調整は必要でしたが。

(参考) Reactive programming with Spring Boot and Webflux

データ連携バッチ (Go on ECS Fargate)

小規模なバッチで、一人で担当しました。goroutine や channel がデータ連携と相性が良さそうだったので Go にしました。

かわったこと

スクラムでお客様と一緒になって開発を進めていくなか、システムを作っているという意識だけでなく、新しいビジネスを創造する過程に携わらせていただいている、という意識を持つようになりました。
具体的な開発としては、以下のような変化がありました。

非正常系に対する意識

以前はバグを出さない、バグ検知を容易にするという観点で、ログ出力などの非正常系の実装を行っていた気がします。

実際には、もっと多くのことを想定して実装する必要があることを認識しました。

例えば外部サービスとの連携に失敗した場合、リトライするのかしないのか、メトリクスにはどのように可視化されるのか、運用管理者への通知はどうするのか、復旧プランはどういうものになるのか、といったように、多くのことを想定して、運用プロセスを含めた設計および実装が必要です。

可用性の認識

これまでは障害はバグのせいだから、バグがないように実装したら障害も発生しない、といった程度の安易な考え方でした。

その考えが間違っていることを今痛感しています。障害は起きるもの、という考えに変わりました。
避けられるものもありますが、プラットフォームや外部連携先での障害といったような避け難いものもあり、そういう前提のうえで、いかにサービス（ビジネス）を止めないようにするかを考える必要があります。

例えば、3rdパーティのサービスと連携する新しい機能を追加する場合、そのサービスに障害があった場合、新しい機能が使えなくなるのはしかたないとしても、その障害により既存の機能が使えなくなるようなことがあってはいけないという感じです。システムが高機能化複雑化するなかで、如何に可用性を確保するかということが重要な観点になります。

コスト意識

コスト意識といえば、開発期間や変更容易性、技術的負債といった程度の認識でした。

開発コストよりも、リリース後のコストを意識するようになりました。開発コストはその期間のみの話ですが、保守コストはそのサービスが存続する限り、永遠に発生します。

インフラにかかるコストについては、初期の見積もりも必要ですが、柔軟に増減させられるような状態にしておき、運用の中で適正値を見つけていくことが現実的なのかなと思っています。
機能面については、保守が楽になる仕組みを、その開発が大変だったとしても行う価値があったりします。
また、ブルーグリーンデプロイメントなど、継続的な開発がサービスを止めずにに容易に繰り返し行えるようにすることで、サービス稼働後の開発コストを抑えることができると思います。